| Oracle® Enterprise Manager Cloud Control Administrator's Guide 12c Release 3 (12.1.0.3) Part Number E24473-24 |
|
|
PDF · Mobi · ePub |
| Oracle® Enterprise Manager Cloud Control Administrator's Guide 12c Release 3 (12.1.0.3) Part Number E24473-24 |
|
|
PDF · Mobi · ePub |
This chapter discusses best practices for installation and configuration of each Cloud Control component and covers the following topics:
The following sections discuss best practices for installation and configuration of the Management Agent.
The Management Agent is started manually. It is important that the Management Agent be automatically started when the host is booted to insure monitoring of critical resources on the administered host. To that end, use any and all operating system mechanisms to automatically start the Management Agent. For example, on UNIX systems this is done by placing an entry in the UNIX /etc/init.d that calls the Management Agent on boot or by setting the Windows service to start automatically.
Once the Management Agent is started, the watchdog process monitors the Management Agent and attempts to restart it in the event of a failure. The behavior of the watchdog is controlled by environment variables set before the Management Agent process starts. The environment variables that control this behavior follow. All testing discussed here was done with the default settings.
EM_MAX_RETRIES – This is the maximum number of times the watchdog will attempt to restart the Management Agent within the EM_RETRY_WINDOW. The default is to attempt restart of the Management Agent three times.
EM_RETRY_WINDOW - This is the time interval in seconds that is used together with the EM_MAX_RETRIES environmental variable to determine whether the Management Agent is to be restarted. The default is 600 seconds.
The watchdog will not restart the Management Agent if the watchdog detects that the Management Agent has required restart more than EM_MAX_RETRIES within the EM_RETRY_WINDOW time period.
The Management Agent persists its configuration, intermediate state and collected information using local files in the agent_inst directory.
In the event that these files are lost or corrupted before being uploaded to the Management Repository, a loss of monitoring data and any pending alerts not yet uploaded to the Management Repository occurs.
To protect from such losses, configure these sub-directories on striped redundant or mirrored storage. The Management Agent agent_inst directory is shown by entering the command 'emctl getemhome' on the command line, or from the Management Services and Repository > Agents tab in the Cloud Control console.
The following sections document best practices for repository configuration.
Before installing Enterprise Manager, you should prepare the database, which will be used for setting up Management Repository. Install the database using Database Configuration Assistant (DBCA) to make sure that you inherit all Oracle install best practices.
Choose Automatic Storage Management (ASM) as the underlying storage technology.
Enable ARCHIVELOG Mode
Enable Block Checksums
Configure the Size of Redo Log Files and Groups Appropriately
Use a Flash Recovery Area
Enable Flashback Database
Use Fast-Start Fault Recovery to Control Instance Recovery Time
Enable Database Block Checking
Set DISK_ASYNCH_IO
The details of these settings are available in Oracle Database High Availability Best Practices.
Use the MAA Advisor for additional high availability recommendations that should be applied to the Management Repository. To access the MAA Advisor:
On the Database Target Home page, locate the High Availability section.
Click Details next to the Console item.
In the Availability Summary section of the High Availability Console page, click Details located next to the MAA Advisor item.
If the Management Repository is a Real Application Cluster (RAC) database, the Management Service processes need to be configured to communicate with each node of the RAC database in a redundant fashion.
Note that RAC nodes are referred to by their virtual IP (VIP) names. The service_name parameter is used instead of the system identifier (SID) in connect_data mode and failover is turned on. Refer to the Oracle Database Net Services Administrator's Guide for details.
Configure the repository connect descriptor by running the emctl command from Management Service. If you have multiple Management Services configured, this command must be run on each Management Service.
emctl config oms -store_repos_details -repos_conndesc '(DESCRIPTION= (ADDRESS_LIST=(FAILOVER=ON) (ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip.example.com)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=node2-vip.example.com)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=EMREP)))' -repos_user sysman
After making the previous change, run the following command from any one OMS to make the same change to the monitoring configuration used for the Management Services and Repository target:
emctl config emrep -conn_desc <repository_connect descriptor as above>
The following sections document the configuring the OMS for high availability.
This section provides a general reference for Cloud Control administrators who want to configure Enterprise Manager Cloud Control in Cold Failover Cluster (CFC) environments.
The following conditions must be met for Cloud Control to fail over to a different host:
The installation must be done using a Virtual Host Name and an associated unique IP address.
Install on a shared disk/volume which holds the binaries and the gc_inst directory.
The Inventory location must failover to the surviving node.
The software owner and time zone parameters must be the same on all cluster member nodes that will host this Oracle Management Service (OMS).
To override the physical host name of the cluster member with a virtual host name, software must be installed using the parameter ORACLE_HOSTNAME.
The software must be installed using the command line parameter -invPtrLoc to point to the shared inventory location file, which includes the path to the shared inventory location.
If you are using an NFS mounted volume for the installation, please ensure that you specify rsize and wsize in your mount command to prevent running into I/O issues.
For example:
oms.example.com:/u01/app/share1 /u01/app/share1 nfs rw,bg,rsize=32768,wsize=32768,hard,nointr,tcp,noac,vers=3,timeo=600 0 0
Note:
Any reference to shared failover volumes could also be true for non-shared failover volumes which can be mounted on active hosts after failover.You can set up the virtual host name and virtual IP address by either allowing the clusterware to set it up, or manually setting it up yourself before installation and startup of Oracle services. The virtual host name must be static and resolvable consistently on the network. All nodes participating in the setup must resolve the virtual IP address to the same host name. Standard TCP tools such as nslookup and traceroute can be used to verify the host name. Validate using the following commands:
nslookup <virtual hostname>
This command returns the virtual IP address and full qualified host name.
nslookup <virtual IP>
This command returns the virtual IP address and fully qualified host name.
Be sure to try these commands on every node of the cluster and verify that the correct information is returned.
Storage can be managed by the clusterware that is in use or you can use any shared file system (FS) volume, such as NFS, as long as it is not an unsupported type, such as OCFS V1.
Note:
Only OCFS V1 is not supported. All other versions of OCFS are supported.If the OHS directory is on a shared storage, the LockFile directive in the httpd.conf file should be modified to point to a local disk, otherwise there is a potential for locking issues.
Some operating system versions require specific operating system patches be applied prior to installing 12c. The user installing and using the 12c software must also have sufficient kernel resources available. Refer to the operating system's installation guide for more details. Before you launch the installer, certain environment variables need to be verified. Each of these variables must be identically set for the account installing the software on ALL machines participating in the cluster:
OS variable TZ
Time zone setting. You should unset this variable prior to installation.
PERL variables
Variables such as PERL5LIB should also be unset to avoid association to the incorrect set of PERL libraries
The user and group of the software owner should be defined identically on all nodes of the cluster. This can be verified using the 'id' command:
$ id -a
uid=550(oracle) gid=50(oinstall) groups=501(dba)
Use the following steps to set up shared inventory:
Create your new ORACLE_HOME directory.
Create the Oracle Inventory directory under the new ORACLE_HOME:
$ cd <shared oracle home>
$ mkdir oraInventory
Create the oraInst.loc file. This file contains the Oracle Inventory directory path information needed by the Universal Installer.
vi oraInst.loc
Enter the path information to the Oracle Inventory directory and specify the group of the software owner as the oinstall user. For example:
inventory_loc=/app/oracle/share1/oraInventory
inst_group=oinstall
Refer to the following steps when installing the software:
Create the shared disk location on both the nodes for the software binaries.
Point to the inventory location file oraInst.loc (under the ORACLE_BASE in this case), as well as specifying the host name of the virtual group. For example:
$ runInstaller -invPtrloc /app/oracle/share1/oraInst.loc ORACLE_HOSTNAME=lxdb.example.com -debug
You can also provide the ORACLE_HOSTNAME when prompted for this information from in Enterprise Manager runInstaller UI.
Install Oracle Management Services on cluster member Host1.
Continue the remainder of the installation normally.
Once completed, copy the files oraInst.loc and oratab to /etc on all cluster member hosts (Host2, Host3, ...)
Windows Specific Configuration Steps
On Windows environments, an additional step is required to copy over service and keys required by the Oracle software. Note that these steps are required if your clustering software does not provide a shared windows registry.
Using regedit on the first host, export each Oracle service from under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.
Using regedit on the first host, export HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE.
Use regedit to import the files created in step 1 and 2 to the failover host.
Ensure that you start your services in the proper order. Use the order listed below:
Establish the IP address on the active node.
Start the TNS listener (if it is part of the same failover group).
Start the database (if it is part of the same failover group).
Start Cloud Control using emctl start oms
Test functionality.
In case of failover, refer to "Performing Switchover and Failover Operations".
In general Enterprise Manager does not store IP address lookups. So if the IP address of the repository host changes but the hostname remains the same, no configuration change in required in Enterprise Manager. Ensure that the OMS(s) hosts can communicate with the repository host with the new IP address.
However if the Repository hostname changes, please use the following procedure to make appropriate configuration changes so that the OMS(s) can communicate with the repository with new hostname.
Stop all OMS instances using the command
$emctl stop oms -all
Stop the Agent running on the database host.
$emctl stop agent
Perform host name change for the machine either by local resolution /etc/hosts or DNS based resolution or a combination of both.
Follow Oracle Database Administrator guide to configure the database for hostname change.
Correct the connect descriptor for the repository by running the following commands:
On the first Oracle Management Service
emctl start oms -admin-only
On each Oracle Management Service
$emctl config oms -store_repos_details -repos_conndesc <connect descriptor> -repos_user sysman
Where <connect descriptor> is the repository connect descriptor using the new hostname.
Note: If Single Client Access Name (SCAN) is configured on the Repository database, it may be possible to change the repository hostname without needing to change the connect descriptor of clients like OMS. Please consult Oracle Database Administrator Guide.
Stop and Start OMS instances using the command:
$emctl stop oms -all
$emctl start oms
The agent installed on the repository host using the old hostname can no longer be used. Install new agent on database host, if RAC database is configured then install new agent on each node. Follow below step to install new agent <include agent installation url for reference>
1. Remove the agent_inst directory .
2. Configure the agent using the agentDeploy.sh command:
$<AGENT_HOME>/core/12.1.0.0.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<AGENT_BASE_DIR> AGENT_INSTANCE_HOME=<AGENT_INSTANCE_HOME> ORACLE_HOSTNAME=<AGENT_HOSTNAME> AGENT_PORT=<AGENT_PORT> -configOnly OMS_HOST=<oms host> EM_UPLOAD_PORT=<OMS_UPLOAD_PORT> AGENT_REGISTRATION_PASSWORD=<REG_PASSWORD>
Relocate the Repository database target to the new Management Agent configured using the following commands:
<OMS_HOME>/bin/emcli login -username=sysman
<OMS_HOME>/bin/emcli sync
<OMS_HOME>/bin/emctl config repos -agent <new agent on host, e.g myNewReposHost.example.com:3872>
Change the monitoring configuration for the OMS and Repository target: by running the following command from the OMS:
$emctl config emrep -conn_desc
Verify that the site is fully operational.
Log in to Cloud Control. Navigate Setup, Manage Cloud Control and click on Health Overview.
Delete old agent target entry.
Verify that the site is fully operational.
In this scenario, you have mulitple OMSs fronted by Server Load Balancer. OMS configuration backed up using the emctl exportconfig oms command on the primary OMS running the WebLogic AdminServer.
Copy the emkey to the Management Repository by running the following command on the OMS:
$<ORACLE_HOME>/bin/emctl config emkey -copy_to_repos
Export the configuration from the OMS.
$<ORACLE_HOME>/bin/emctl exportconfig oms -dir <location for the export file>
After the configuration is exported, do not make any configuration changes to the OMS until hostname change is configured.
Deconfigure and delete the OMS
Stop the OMS $<ORACLE_HOME>/bin/emctl stop oms -all
Stop the agent running $<AGENT_HOME>/bin/emctl stop agent
Delete the OMS $<OMS_HOME>/bin/omsca delete -full
For example:
/u01/app/Oracle/Middleware/oms/bin/omsca delete -full
Note : You are prompted to confirm your action, and furnish the AdminServer credentials and the repository database details such as the database host name, listener port, SID, and password. Once you provide the required details, the command automatically stops the OMS, Oracle WebLogic Server, and also Oracle WebTier.
Delete following file from the Oracle Home
Also, delete Instance home directory gc_inst, if it exists.
Make sure no process running on the OMS host.
ps -ef | grep -i -P "(Middleware|gc_inst)" | grep -v grep | awk '{print $2}' | xargs kill -9
Note : Change Middleware|gc_inst to strings that match your own middleware and instance homes
Perform hostname change for the machine either by local resolution /etc/hosts or DNS based resolution or a combination of both.
Run omsca in recovery mode specifying the export file taken earlier to configure the OMS:
<OMS_HOME>/bin/omsca recover -as -ms -nostart -backup_file <exportconfig file> -EM_INSTANCE_HOST <new hostname> -AS_HOST <new hostname>
Note: The -backup_file to be passed must be the latest file generated from emctl exportconfig oms command in Step 2.
Provide new hostname for -EM_INSTANCE_HOST and -AS_HOST
Add the new hostname to the SLB virtual server pools and remove the old OMS entry.
Start the OMS
<OMS_HOME>/bin/emctl start oms
Configure the Management Agent.
Remove the agent_inst directory .
Configure the agent using the agentDeploy.sh command:
$<AGENT_HOME>/core/12.1.0.0.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<AGENT_BASE_DIR> AGENT_INSTANCE_HOME=<AGENT_INSTANCE_HOME> ORACLE_HOSTNAME=<AGENT_HOSTNAME> AGENT_PORT=<AGENT_PORT> -configOnly OMS_HOST=<oms host> EM_UPLOAD_PORT=<OMS_UPLOAD_PORT> AGENT_REGISTRATION_PASSWORD=<REG_PASSWORD>
The additional OMS must be re-enrolled so that they can communicate with the admin server running on the new host. Do the following on each additional management service.
enroll oms -as_host <newhostname> -as_port <AdminServer_ssl_port>
Note: You will be prompted to provided password for admin and node manager.
Login to EM console. Navigate to Setup, Provisioning and Patching and click on Software library. If software library location is configured, verify it is accessible. If not accessible then follow software library configuration document to either migrate or configure new.
<swlib configuration location>
Verify that the site is fully operational.
In this scenario, you have multiple OMS sites where the OMS instances are fronted by an SLB. OMS configuration backed up using the emctl exportconfig oms command on the first OMS. Hostname change is required on Additional OMS host.
Stop the OMS using below command
$<ORACLE_HOME>/bin/emctl stop oms
Stop the agent running on the host
$<AGENT_HOME>/bin/emctl stop agent
Deconfigure and delete the OMS:
Delete the OMS $<OMS_HOME>/bin/omsca delete -OMSNAME <Additional OMS Name>
For example:
/u01/app/Oracle/Middleware/oms/bin/omsca delete -OMSNAME EMGC_OMS2
Note: You are prompted to confirm your action, and furnish the AdminServer credentials and the repository database details such as the database host name, listener port, SID, and password. Once you provide the required details, the command automatically stops the OMS, Oracle WebLogic Server, and also Oracle WebTier.
Delete following file from the Oracle Home
Delete the Instance home directory gc_inst, if it exists.
Make sure no process running on the OMS host.
ps -ef | grep -i -P "(Middleware|gc_inst)" | grep -v grep | awk '{print $2}' | xargs kill -9
Note : Change Middleware|gc_inst to strings that match your own middleware and instance homes
Perform hostname change for the machine either by local resolution /etc/hosts or DNS based resolution or a combination of both.
Ensure that shared software library locations are accessible.
Install an Management Agent on the required host using new hostname.
Remove the agent_inst directory .
Configure the agent using the agentDeploy.sh command:
$<AGENT_HOME>/core/12.1.0.0.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<AGENT_BASE_DIR> AGENT_INSTANCE_HOME=<AGENT_INSTANCE_HOME> ORACLE_HOSTNAME=<AGENT_HOSTNAME> AGENT_PORT=<AGENT_PORT> -configOnly OMS_HOST=<oms host> EM_UPLOAD_PORT=<OMS_UPLOAD_PORT> AGENT_REGISTRATION_PASSWORD=<REG_PASSWORD>
Use the Additional OMS deployment procedure to configure a new additional OMS. See the Oracle® Enterprise Manager Cloud Control Basic Installation Guide for more information.
Verify that the site is fully operational.
The following sections discuss how to configure the OMS for high availability failover in an Active/Active environment using a Server Load Balancer.
The software library location must be accessible by all active Management Services. If the software library is not configured during installation, it needs to be configured post-install using the Enterprise Manager console.:
On the Enterprise Manager home page, from the Setup menu, select Provisioning and Patching, and then select Software Library.
Click the Provisioning subtab.
On the Provisioning page, click the Administration subtab.
In the Software Library Configuration section, click Add to set the Software Library Directory Location to a shared storage that can be accessed by any host running the Management Service.
This section describes the guidelines for setting up a Server Load Balancer (SLB) to balance the agent and browser traffic to multiple Management Services.
Server Load Balancer Requirements
In order to configure your OMS's in an active/active configuration behind an SLB, your SLB must meet the following requirements:
The SLB must provide support for multiple virtual server ports.
Enterprise Manager typically requires that up to 4 ports are configured on the SLB (Secure Upload, Agent Registration, Secure Console, Unsecure Console)
Support for persistence.
HTTP and HTTPS traffic between the browser and the OMS requires persistence.
Support for application monitoring.
The SLB must be capable of monitoring the health of the OMSs and detecting failures, so that requests will not be routed to OMSs that are not available.
SLB configuration is a two-step process:
Configure the SLB.
Make requisite changes on the Management Services.
Use the following table as reference for setting up the SLB with Cloud Control Management Services.
Table 27-1 Management Service Ports
| Cloud Control Service | TCP Port | Monitor Name | Persistence | Pool Name | Load Balancing | Virtual Server Name | Virtual Server Port |
|---|---|---|---|---|---|---|---|
|
Secure Upload |
4900 |
mon_gcsu4900 |
None |
pool_gcsu4900 |
Round Robin |
vs_gcsu4900 |
4900 |
|
Agent Registration |
4889 |
mon_gcar4889 |
Active Cookie Insert |
pool_gcar4889 |
Round Robin |
vs_gcar4889 |
4889 |
|
Secure Console |
7799 |
mon_gcsc7799 |
Source IP |
pool_gcsc7799 |
Round Robin |
vs_gcsc443 |
443 |
|
Unsecure Console (optional) |
7788 |
mon_gcuc7788 |
Source IP |
pool_gcuc7788 |
Round Robin |
vs_gcuc80 |
80 |
Use the administration tools that are packaged with your SLB. A sample configuration follows. This example assumes that you have two Management Services running on host A and host B using the default ports as listed in Table 33–1.
Create Pools
A pool is a set of servers grouped together to receive traffic on a specific TCP port using a load balancing method. Each pool can have its own unique characteristic for a persistence definition and the load-balancing algorithm used.
| Pool Name | Usage | Members | Persistence | Load Balancing |
|---|---|---|---|---|
|
pool_gcsu4900 |
Secure upload |
HostA:4900 HostB:4900 |
None |
Round Robin |
|
pool_gcar4889 |
Agent registration |
HostA:4889 HostB:4889 |
Active cookie insert; expiration 60 minutes |
Round Robin |
|
pool_gcsc7799 |
Secured console access |
HostA:7799 HostB:7799 |
Source IP; expiration 60 minutes |
Round Robin |
|
pool_gcuc7788 (optional) |
Unsecured console access |
HostA:7788 HostB:7788 |
Source IP; expiration 60 minutes |
Round Robin |
Create Virtual Servers
A virtual server, with its virtual IP Address and port number, is the client- addressable hostname or IP address through which members of a load balancing pool are made available to a client. After a virtual server receives a request, it directs the request to a member of the pool based on a chosen load balancing method.
Create Monitors
Monitors are used to verify the operational state of pool members. Monitors verify connections and services on nodes that are members of load-balancing pools. A monitor is designed to check the status of a service on an ongoing basis, at a set interval. If the service being checked does not respond within a specified timeout period, the load balancer automatically takes it out of the pool and will choose the other members of the pool. When the node or service becomes available again, the monitor detects this and the member is automatically accessible to the pool and able to handle traffic.
| Monitor Name | Configuration | Associate With |
|---|---|---|
|
mon_gcsu4900 |
Type: https Interval: 60 Timeout: 181 Send String: GET /empbs/upload Receive String: Http Receiver Servlet active! |
HostA:4900 HostB:4900 |
|
mon_gcar4889 |
Type: http Interval: 60 Timeout: 181 Send String: GET /empbs/genwallet Receive String: GenWallet Servlet activated |
HostA:4889 HostB:4889 |
|
mon_gcsc7799 |
Type: https Interval: 5 Timeout: 16 Send String: GET /em/consoleStatus.jsp Receive String: Enterprise Manager Console is UP |
HostA:7799 HostB:7799 |
|
mon_gcuc7788 (optional) |
Type: http Interval: 5 Timeout: 16 Send String: GET /em/consoleStatus.jsp Receive String: Enterprise Manager Console is UP |
HostA:7788 HostB:7788 |
Note: Some Load Balancers require <CR><LF> characters to be added explicitly to the Send String using literal "\r\n". This is vendor-specific. Refer to your SLB documentation for details.
Perform the following steps:
Resecure the Oracle Management Service
By default, the service name on the Management Service-side certificate uses the name of the Management Service host. Management Agents do not accept this certificate when they communicate with the Oracle Management Service through a load balancer. You must run the following command to regenerate the certificate on each Management Service:
emctl secure oms -host slb.example.com -secure_port 4900 -slb_port 4900 -slb_console_port 443 -console [-lock] [-lock_console]
Output:
Oracle Enterprise Manager Cloud Control 12c Release 3 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. Securing OMS... Started. Enter Enterprise Manager Root (SYSMAN) Password : Enter Agent Registration Password : Securing OMS... Successful Restart OMS
Resecure all Management Agents
Management Agents that were installed prior to SLB setup, including the Management Agent that comes with the Management Service install, would be uploading directly to the Management Service. These Management Agents will not be able to upload after SLB is setup. Resecure these Management Agents to upload to the SLB by running the following command on each Management Agent:
emctl secure agent –emdWalletSrcUrl https://slb.example.com:<upload port>/em
There are two ways to install additional Management Services:
Using the Add Additional OMS Deployment Procedure (preferred method). For more information about using this deployment procedure, see the chapter on Adding Additional Oracle Management Service in the Oracle® Enterprise Manager Cloud Control Basic Installation Guide.
Installing Additional Oracle Management Service in Silent Mode (alternative method). For more information about silent mode installation, see the Oracle® Enterprise Manager Cloud Control Advanced Installation and Configuration guide.
|
 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
